fix(browser-session): require aggregate-issued lifecycle request authority - #317

Exact-head security finding on 97e0a4d875166ad733e78c1d3f213454ee615f01: the new lifecycle request is non-caller-constructible, but its port ownership is still self-asserted through public DisposableContextPortId::new(u64) plus DisposableContextPort::port_id(). Two distinct adapter instances can both report port_id=101; after A is bound, Browser Session's equality check will accept B as the same port. More strongly, A can relay the borrowed aggregate-issued create/destroy request to B, and B can satisfy the same scalar equality and reach remote lifecycle I/O even though B was never the aggregate-approved adapter instance. The current hostile test only uses 101 vs 102, so it proves mismatch rejection but not non-forgeable adapter ownership.

Required RED before this prerequisite can be GREEN: bind adapter A with id 101, then use distinct adapter B also claiming id 101; B must be rejected before create/destroy I/O and must not be able to consume/replay A's request. Do not repair this by documenting port-id uniqueness or randomizing a public scalar. The binding itself needs a non-caller-constructible Browser Session-approved/linear port capability or equivalent identity that a second adapter cannot self-select or replay. Keep remote BiDi identifiers outside Browser Session domain truth.

Separately, current hosted CI 34520503299 is still RED at rustfmt before tests/Clippy/rustdoc, and coverage measurement also fails; fix that operational RED without weakening gates after the authority model is corrected.

Exact-head security finding on 9caf9bbe4228c443b7d5a4279831765a6a38765a: the current port-binding preflight still cannot guarantee the stated “reject before lifecycle I/O” boundary because bind_lifecycle_port / require_bound_lifecycle_port call the public trait method DisposableContextPort::port_id(&self) before issuing or validating the aggregate request. Rust &self is not a purity guarantee: an implementation can use interior mutability, a socket/client handle, atomics, or delegated state and perform remote side effects from port_id(). The rustdoc requirement that port_id be side-effect-free is therefore a convention, not an enforced security invariant. The same problem remains even after replacing the scalar id with a harder-to-forge value if Browser Session must first invoke an arbitrary adapter callback to discover/validate that value.

Required RED: use a hostile port whose identity/preflight callback records a lifecycle side effect, then exercise (a) a first create attempt and (b) a mismatched destroy/create attempt that Browser Session is expected to reject. Both must show zero adapter/browser mutation before an aggregate-issued authority exists and is validated. Do not satisfy this by documenting port_id() purity or by testing only the reviewed WebDriver adapter implementation.

Causal direction: remove authority-sensitive identity discovery from an arbitrary preflight callback. Establish the lifecycle-port binding through a non-caller-constructible composition/binding capability (or a session-owned/linear port wrapper) before lifecycle mutation, then invoke the adapter only under the already validated create/destroy request. If DisposableContextPort remains externally implementable, the contract must not rely on &self implying side-effect freedom. Preserve the current same-id/different-adapter hostile RED and the requirement that requests cannot be replayed into a different bound adapter. Keep remote BiDi identifiers outside Browser Session domain truth.

Merge-blocking integration finding on exact 9cde981899950b900698a17e7fa739af59f6bb4f: the linear BoundBrowserSession<P> closes caller-side port substitution, but the lifecycle contract still has no aggregate→adapter completion phase for creation, and DisposableContextCreateRequest is not unique per create attempt. Every create request in one Browser Session incarnation exposes only the same (BrowserSessionId, BrowserSessionIncarnation) pair, even though BrowserSession already reserves a distinct context epoch before remote I/O. After port.create_disposable_context(&request) returns, the aggregate may accept the handle or reject it as duplicate/ambiguous and enter RecoveryRequired, but DisposableContextPort receives no accept/reject completion carrying a per-attempt identity. A BiDi adapter implementing #316 therefore cannot deterministically move the exact remote tuple from pending→accepted or pending→quarantine without inventing adapter-local correlation/authority, keying only by the same session/incarnation, relying on call order, or prematurely authorizing before Browser Session validation.

Required RED before adoption: one bound port produces at least two creation candidates in the same Browser Session incarnation, retains them as separate pending protocol tuples, and Browser Session accepts one while rejecting the other (e.g. duplicate domain context/isolation). The adapter must promote only the accepted candidate and quarantine exactly the rejected candidate; neither candidate may collide/overwrite because their create requests are indistinguishable. No remote tuple may become authorizing before aggregate acceptance.

Causal repair should extend the Browser Session-owned transaction boundary, not move BiDi ids into this domain: mint a non-caller-constructible per-attempt lifecycle identity/capability (the already-reserved epoch is a natural candidate if its semantics fit), pass it in the create request, and provide an aggregate-issued accept/reject completion that the exact bound port consumes. The adapter keeps protocol tuples pending until that completion. Preserve structural port binding and the existing no-preflight/same-id hostile tests. #316 remains the owner of remote BiDi pending/accepted/quarantine data; #317 should only provide the domain transaction identity/completion contract it needs.

Additional lifecycle-ordering acceptance from stacked #318 exact f936f8b8259e096bd4fb850756245cda99c583cc: when record_transport_loss() has already moved Browser Session to TransportLost (or an ownership failure has moved it to RecoveryRequired), a buffered/replayed browser navigation observation must not be accepted as new current-state evidence. record_observed_navigation(context) should gate on aggregate state before context/presentation state, fail closed as SessionNotActive, perform zero adapter I/O, leave the exact recovery-evidence set unchanged, and never revive a retained pre-loss authority. This closes a realistic asynchronous event-ordering race: the dead/untrusted transport is not allowed to advance presentation lifecycle after recovery handoff has begun. The RED is test-only on #318; no #317 source mutation here.

Follow-up Browser Session acceptance from #318 exact 6bfd0d085145096756332f270e1fa5e803fdcbf3: when the causal source repair lands here, aggregate trust state must gate the lower-level context state before ownership lookup/idempotency. In RecoveryRequired, reestablish_presentation_authority(context) and ordinary owned-context cleanup retry must fail specifically as SessionNotActive, while state remains RecoveryRequired and the existing unproven-destruction evidence is unchanged; ContextNotOwned would falsely prove lifecycle ownership was consumed. Likewise, a buffered/replayed observed-navigation after TransportLost must return SessionNotActive and leave the aggregate exactly TransportLost with identical recovery evidence. CodeRabbit independently verified these RED refinements on #318. This is additive to the existing exact handle+epoch and same-adapter recovery blockers, not a replacement for them.

#318 exact fbfed17af630113af5aaec9d1af37790fae77a4e adds the remaining aggregate-trust ordering RED for the normal terminal state. After an owned disposable context is proven destroyed and Browser Session reaches Ended, both the formerly-owned BrowsingContextId and a foreign raw selector must be rejected by record_observed_navigation(...) as SessionNotActive before any ownership/history lookup, with zero adapter I/O, exact Ended state preserved, and recovery evidence unchanged. This closes the same ownership-oracle class already covered for TransportLost and RecoveryRequired: the navigation transition is valid only while the aggregate is Active; Ended must gate before per-context lookup/idempotency. No #317 source mutation is requested from this test lane.

#318 exact e0407dd9314e9eface64cad10a0b03dda8e0b096 adds one missing lifecycle-ordering RED for the #317 production repair: after observed-navigation invalidation and proven destroy_owned_disposable_context(context), the Browser Session remains reusable/Active, but a buffered/late navigation notification for that now-consumed context must be rejected as ContextNotOwned before adapter I/O. The rejection must not manufacture recovery evidence or consult historical tombstones in a way that resurrects presentation/lifecycle ownership. An unrelated foreign selector has the same active-state rejection semantics. This is intentionally distinct from the existing Ended/TransportLost/RecoveryRequired aggregate-first gate: while the aggregate is still Active, lifecycle ownership consumption is authoritative and historical ownership must not become observation authority. Please preserve this in the causal #317 state-model repair together with bounded hot ownership state.

#318 exact 79e8db01f8ccf8297a2855dad9254d3db33a03f9 exposes one additional Browser Session blocker before the navigation-invalidation successor can turn GREEN. A raw-id-only record_observed_navigation(BrowsingContextId) cannot distinguish a delayed replay from a distinct later navigation once presentation authority has been explicitly re-established. The old event can therefore invalidate the newly current authority.

Required causal repair: bind the observed-navigation transition to the exact current BrowserContextEpoch. While aggregate state is Active, matching current epoch invalidates; duplicate delivery of the same already-invalidated epoch is idempotent; after reestablish_presentation_authority advances the epoch, replay of the prior epoch must return AuthorityMismatch with zero adapter I/O and leave current authority usable. Inactive aggregate gates (Ended/TransportLost/RecoveryRequired) remain higher priority, and consumed ownership remains ContextNotOwned.

This is generation correlation, not adapter authority. #316 still owns WebDriver BiDi event identity/replay qualification; Browser Session owns deterministic acceptance of the supplied domain generation. Please include this with the existing operation/destroy epoch-correlation repair rather than exposing another raw selector transition.

Follow-up Browser Session finding from #318 exact 8f1678f09017387c3f6d2d0aaedbaa83cbdd0489: observed-navigation epoch correlation must be scoped to the exact owned context, not merely to a session-global epoch namespace. A sibling owned context's current BrowserContextEpoch supplied with another context id must fail AuthorityMismatch before any adapter I/O and must not invalidate either context. The new RED creates two simultaneously owned contexts, proves their epochs differ, attempts cross-context epoch substitution, then verifies both authorities remain usable before applying the exact matching navigation to only one context. Production repair should compare (BrowsingContextId, current BrowserContextEpoch, presentation-validity state) as one context-generation fact after aggregate trust gating; do not accept “any issued/current epoch in this BrowserSession” as sufficient navigation provenance.

#318 exact da9c8f1b3e9ec61a6f75d6e6e5058426ded07820 adds a hostile cross-session navigation-generation RED. Current desired (BrowsingContextId, BrowserContextEpoch) correlation aliases across independent Browser Session aggregates because each aggregate can reuse the same external BrowserSessionId/BrowsingContextId and allocate the same local epoch value. The process-local BrowserSessionIncarnation is the existing discriminator and is already carried by lifecycle/operation authority. Minimum source repair should gate aggregate activity, then reject observed-navigation provenance whose incarnation differs from self.incarnation before any context lookup or adapter I/O; only after that validate exact context+epoch/presentation state. The incarnation remains non-authorizing provenance. Do not solve this by making epochs globally mutable/shared or by moving authority into the BiDi adapter.

#318 exact da28f1d64df2c521a9537bf8a70155f75effa920 found one additional source blocker in the navigation authority model: invalidation on navigation start is not enough if reestablish_presentation_authority may succeed immediately afterward. WebDriver BiDi exposes distinct navigationStarted and navigationCommitted events (plus fragmentNavigated, navigationAborted, navigationFailed), so a start observation does not prove the new document transition has settled.

Required Browser Session behavior: after exact incarnation+context+epoch navigation start, presentation remains invalidated and re-establishment must fail zero-I/O until a matching generation is explicitly settled. Settlement must be a zero-I/O domain transition, consume no authority epoch, and stale settlement from an older epoch/incarnation must fail AuthorityMismatch. Proven lifecycle cleanup must remain possible while navigation is still pending. #316 should own protocol event-id/replay matching; core should consume only a qualified settled-generation transition and must not treat W3C navigation ids as mutation authority.

Follow-up from #318 exact 56b3d41ee514ada9c9c02b01313c3996ef0b2f89: the new settlement transition needs the same non-aliasing checks as navigation-start invalidation, not merely the same method signature. Hostile RED now proves that an invalidated context cannot be marked settled by a sibling context's epoch, and that a prior BrowserSessionIncarnation cannot settle a current aggregate even when raw session/context/epoch values numerically alias. Both cases must fail AuthorityMismatch, perform zero adapter I/O, and keep re-establishment closed until the exact current incarnation+context+epoch is settled. This should be implemented in the Browser Session aggregate before any new authority epoch is issued.

#318 exact b72ab18593f1fe0b622bccca4f1e39c254bb50d8 found a stricter Browser Session authority defect in the proposed navigation-settlement contract. Treating (BrowserSessionIncarnation, BrowsingContextId, BrowserContextEpoch) as non-authorizing provenance but allowing record_observed_navigation_settled(incarnation, context, epoch) to unlock presentation re-establishment makes the reconstructible tuple a de facto capability.

Production acceptance should instead have Browser Session validate the exact start provenance and issue an opaque, non-constructible NavigationSettlementAuthority bound to that aggregate/pending generation. record_observed_navigation_settled must validate that aggregate-issued witness rather than accept raw ids. Cross-aggregate witness substitution must fail AuthorityMismatch before I/O even when external session/context ids and local epoch values alias. W3C NavigationInfo.navigation remains adapter correlation evidence, never Browser Session policy authority.

Also correcting my earlier standards handoff: the canonical W3C TR page currently identifies 9 September 2026 as the published Working Draft (WD-webdriver-bidi-20260909) and links the Editor’s Draft separately. The prior 24-August objection should not block this PR. Runtime qualification remains a separate explicit decision.

#318 exact successor found one remaining Browser Session availability/security gap in the navigation state machine. The 9 Sep 2026 WebDriver BiDi WD has distinct terminal browsingContext.navigationAborted and browsingContext.navigationFailed events carrying NavigationInfo; a design that only accepts commit/fragment as settlement leaves an admitted navigationStarted generation permanently pending after abort/failure. That is a fail-closed state which can become a durable self-DoS, not a safe terminal policy state.

Production acceptance should therefore distinguish successful settlement from negative terminal observation. After aggregate trust and exact opaque pending-navigation witness validation, an equivalent of record_observed_navigation_terminated(&NavigationSettlementAuthority, NavigationTerminationOutcome::{Aborted, Failed}) must consume that pending witness with zero adapter I/O. It must NOT silently mint or restore PresentationMutationAuthority; the pre-navigation authority stays stale. If lifecycle ownership remains active, explicit bound-owner re-establishment may then issue one fresh epoch so the still-usable context is not stranded. Replaying the consumed witness must be AuthorityMismatch and must not affect a newer generation. Raw session/context/epoch or W3C navigation ids remain evidence, not policy authority.

#318 now carries the repository contract plus hostile failure/abort RED on its current lineage. Please implement this together with the existing navigation-pending / settlement / re-establishment repair rather than treating abort/failure as an adapter-only no-op.

#318 exact c5e0cb445758747b57c117220ccfe13ebf9bd5de adds a new hostile Browser Session RED: one aggregate-issued NavigationSettlementAuthority must admit exactly one terminal outcome across the positive and negative APIs, not once per API. After record_observed_navigation_settled(&witness) succeeds, record_observed_navigation_terminated(&witness, Failed|Aborted) must be zero-I/O AuthorityMismatch; after negative termination succeeds, later positive settlement of the same witness must likewise fail. Otherwise separate consumption ledgers/state paths let reordered or duplicated BiDi terminal evidence rewrite an already-terminal navigation generation. Production acceptance should use one shared pending-navigation record/witness consumption state for committed/fragment-settled and failed/aborted outcomes, with terminal outcome assignment monotonic and single-use. This is core policy-state protection; #316 remains responsible for protocol correlation/replay filtering.

#318 exact 13454f971c0d8de7a290a08b0c39d01ecd3e57b7 found one additional production invariant for this owner lane: NavigationSettlementAuthority lifetime must be bounded by aggregate trust, not only by pending-navigation terminal assignment. If a witness was issued while Active and the aggregate later becomes TransportLost, RecoveryRequired, or Ended, both record_observed_navigation_settled and record_observed_navigation_terminated must gate on aggregate state first and return SessionNotActive before witness validation/adapter I/O. Inactive terminal replay must not consume the witness, rewrite recovery evidence, or reopen presentation re-establishment. This prevents an adapter-buffered capability from outliving the Browser Session trust boundary.

#318 exact a6ca33234eefdfcb6380363e60089940e01cf67b exposes one additional production invariant for this owner lane: a pending navigation witness must not outlive the exact context ownership that existed when it was minted.

The aggregate may still be Active after proven destruction, so require_active() alone is insufficient. For both positive settlement and negative termination, the causal validation order should remain fail-closed: aggregate trust → opaque pending-witness identity → witness-bound context/generation is still live-owned → exactly-once terminal assignment. Once proven destruction consumes the context, any pre-destroy pending witness must fail zero-I/O as ContextNotOwned; it must not mutate historical tombstones/pending state, create recovery evidence, or permit later presentation re-establishment. This complements the existing TransportLost/RecoveryRequired/Ended witness-death rule rather than replacing it.

Please make context destruction and pending-navigation capability invalidation one monotonic aggregate transition (or an equivalent invariant with no observable gap). Do not preserve the pending witness merely because the aggregate remains reusable for other contexts.

#318 exact ea85d9f8ec60b87a70cc32ded7bfb02071a3c03f adds one more Browser Session RED: a second adapter-qualified navigationStarted for the same owned context may arrive before the first navigation reaches any terminal event. Core cannot treat the first pending witness as the only admissible generation, because a newer navigation can supersede it while presentation authority is already invalidated. The second qualified start should issue a new opaque pending witness without minting a presentation epoch; the prior witness becomes permanently superseded. Late commit/abort/failure for the superseded witness must be zero-I/O AuthorityMismatch and must not permit reestablish_presentation_authority while the newer navigation remains pending. Only the current pending witness may settle/terminate and allow explicit fresh authority. Adapter replay/identity qualification remains #316; Browser Session should not consume the W3C navigation id as policy authority.

#318 current acceptance repair adds two production blockers that should remain explicit in the #317 Browser Session state machine. First, positive settlement must be scoped to the exact current pending witness/context: settling context A must not clear context B's pending navigation even within the same aggregate. Second, same-context supersession must reject both late negative and late positive terminal evidence for navigation A while navigation B is pending; checking only Pending plus aggregate/context is insufficient. The production order should remain aggregate trust gate → exact current pending-witness identity/context → exact live ownership → single terminal assignment. #318 exact 7a4ec9a6398d3583c76dd668d052a596613c325b contains independent REDs for sibling positive settlement and superseded positive settlement. No #317 source mutation is requested from this test-lane writer.

#318 exact successor d89695f3c84c5538b9bb2e29e6b91d08ba54a572 adds a distinct Browser Session RED for a browser navigation that starts after the prior navigation has terminally settled but before the owner has re-established presentation authority. This race is different from overlapping-pending supersession: the context remains live, no new presentation epoch has been minted, and the browser can move again before control-plane reauthorization. Production must accept the later adapter-qualified start against the still-current invalidated context generation, issue a fresh current pending witness without spending an epoch, and keep re-establishment closed until that latest witness reaches a terminal outcome. Otherwise the prior terminal event can authorize a document that has already navigated again, or the aggregate can reject legitimate browser lifecycle evidence and drift from remote state. Preserve aggregate trust and exact live ownership gates; stale prior terminal replay remains zero-I/O AuthorityMismatch.

#318 acceptance handoff from exact 575496c6276c50bd2d3f3e98a3f230811a688619: the state machine must admit a later adapter-qualified navigation start not only after positive settlement but also after NavigationTerminationOutcome::{Failed, Aborted} when presentation authority has not yet been explicitly re-established. The later start stays on the same live invalidated context generation, spends no presentation epoch, issues a new opaque pending witness, and makes the consumed prior witness permanently dead across both positive and negative terminal APIs. Re-establishment remains AuthorityMismatch until the latest witness reaches its own terminal outcome. This prevents a negative terminal from becoming an availability barrier or from authorizing the document after a newer navigation has already started. Preserve ordering: aggregate trust → exact live context generation/ownership → current pending witness identity → exactly-once terminal assignment → explicit re-establishment.

Coverage execution from stacked #318 exact 6e73ca40a5a17a925223212c18e4396b6c2433ec reached the production compile path and surfaced a real deprecation in this #317 source head under the repository's pinned coverage nightly (nightly-2026-08-18, rustc 1.100.0-nightly): AtomicU64::fetch_update is deprecated in favor of try_update at crates/originweave-browser-session/src/lib.rs:544 and :1021. This is production-owner work, so I did not mutate #317 from the #318 acceptance lane. Please root-fix both call sites (preserving ordering and closure semantics) in this owner branch rather than suppressing the warning; rerun exact-head tests/Clippy/rustdoc/coverage afterward. Evidence: Actions run 34724287752, Production coverage job 103635577342.

Fresh #318 RED found a remaining Browser Session authority bypass requirement. advance_context_epoch(context) is currently a public generic authority-minting path on both BrowserSession and BoundBrowserSession. Pending-navigation RED already required it to fail after navigationStarted, but terminal handling had not proved that the path stays closed after a matching positive settlement or typed Failed/Aborted terminal and before explicit reestablish_presentation_authority.

#318 exact successor 5eedff35e9babb06538952429a64d23be5e9e35d now requires advance_context_epoch to return AuthorityMismatch with zero adapter I/O in all of those settled/terminated-but-not-reestablished states, including terminal-then-later-navigation flow. This matters because settlement/termination intentionally spends no presentation epoch; letting generic rotation mint at that point makes the explicit re-establishment gate advisory rather than authoritative.

Production repair in this owner lane should make navigation-invalidated state dominate every presentation-authority mint path: advance_context_epoch may remain usable for an established context if other bounded contexts require it, but it must not transition a navigation-invalidated context back to authority. Only exact current terminal assignment followed by explicit reestablish_presentation_authority may consume the next aggregate epoch. Preserve aggregate-wide monotonic epoch allocation and zero adapter I/O. No #317 source was mutated from #318.

#318 exact successor c454ee2fec48473fb0f4655b6c670310ab448f01 found a remaining Browser Session invariant: one terminal navigation transition must authorize at most one explicit reestablish_presentation_authority(context) call. After the first successful re-establishment, a duplicate call with no newer navigation must return AuthorityMismatch, perform zero adapter I/O, spend no aggregate epoch, and leave the current presentation authority intact. A later genuinely observed navigation may then invalidate that current generation and, after its own matching terminal outcome, permit exactly one new re-establishment. Please implement this as consumption of the navigation-invalidated/re-establishment eligibility in the #317 aggregate state machine rather than as a caller-side guard. Generic advance_context_epoch remains a separate established-context operation and must not be used as navigation re-establishment. #318 adds hostile RED navigation_reestablishment_is_single_use.rs plus doctoring for this boundary.

#318에서 추가로 확인된 Browser Session owner finding입니다. 현재 acceptance는 terminal outcome 뒤 explicit re-establishment eligibility가 생기지만, 그 사이 exact context가 proven destruction되면 그 eligibility도 ownership과 함께 소멸해야 합니다. settled/terminated → destroy_owned_disposable_context(context) → reestablish_presentation_authority(context)는 ContextNotOwned, zero additional adapter I/O여야 하며 aggregate는 Active, recovery evidence는 불변이어야 합니다. 그렇지 않으면 이미 파괴된 context를 과거 navigation terminal transition으로 다시 authority-mint하는 resurrection 경로가 생깁니다. Production state machine에서 terminal-derived re-establishment eligibility를 context ownership과 별도 dangling flag로 두지 말고 exact live ownership record에 종속시키는 쪽이 causal fix입니다. #318 commits f9110ecf7d756693f8161f9762ee82de9ad4f72c + ad5ec10762bc29e63adb55bf8edd6077b5f216c9에 positive/negative RED와 doctoring을 추가했습니다.

New Browser Session owner finding from #318 acceptance lane: terminal-derived reestablish_presentation_authority eligibility must die when aggregate trust is lost after the terminal event but before re-establishment. Exact #318 RED lineage starts at a2fe20fcdd8e10df94391b3b276b84a43d3bf735; doctoring is synchronized at 7472e6611b0a3136f975b1ab0bcb00236acef205.

Production invariant: after a matching positive settlement, record_transport_loss() must dominate the prior terminal transition; reestablish_presentation_authority(context) must return SessionNotActive, perform zero adapter I/O, leave TransportLost unchanged, and preserve recovery evidence. Likewise, after a matching negative terminal, an unproven destroy that moves the aggregate to RecoveryRequired must make the prior re-establishment eligibility unusable; the same call must return SessionNotActive and preserve exact recovery evidence.

Please bind terminal-derived re-establishment eligibility to aggregate active trust, not to a dangling per-context boolean. This complements the existing exact-context-ownership finding: both aggregate trust and live ownership must dominate eligibility before any fresh presentation epoch can be minted. #318 remains test-first and does not modify this production branch.